Updates to the ES model to allow the configuration of an ES-import route target #1109
Conversation
…ute target * Add a new leaf "es-import-route-target" to the Ethernet Segment config model to allow the explicit configuration of an ES-import route target as per RFC7432 Section 7.6
|
The ES import route target is autoderived in case of ES types 1, 2 and 3, and may be autoderived in the rest of the cases too. That is what other implementations do as well. So I don't think this change is necessary... |
|
RFC7432 only specifies how the ES-import RT can be auto-derived from ES types 1, 2, and 3. In particular, for type 0 ESs, since they're operator configured and completely arbitrary, and the RFC doesn't specify any way to do auto-derivation for that type, I think this is required at least to be able to properly support type 0 ESs in a general way. |
…ute target * Add a new leaf "es-import-route-target" to the Ethernet Segment config model to allow the explicit configuration of an ES-import route target as per RFC7432 Section 7.6 * Make this new "es-import-route-target" leaf conditional on the type of ESI being Type 0 (operator configured), as types 1, 2, and 3 can be auto-derived from the ESI (it's possible for types 4 and 5 to be as well, but that's not called out in the RFC, so leave those alone for now, they can be added to the when statement in the future if necessary)
…ute target * Add a new leaf "es-import-route-target" to the Ethernet Segment config model to allow the explicit configuration of an ES-import route target as per RFC7432 Section 7.6 * Make this new "es-import-route-target" leaf conditional on the type of ESI being Type 0 (operator configured), as types 1, 2, and 3 can be auto-derived from the ESI (it's possible for types 4 and 5 to be as well, but that's not called out in the RFC, so leave those alone for now, they can be added to the when statement in the future if necessary)
|
I updated the PR to add a when clause to the new "es-import-route-target" leaf to make it only apply when the ESI type is Type-0, which should make this a bit cleaner to use. As mentioned earlier, types 1, 2, and 3 are defined by the RFC to be auto-derived from the ESI, so don't require an explicitly specified es-import-rt. Types 4 and 5 aren't specified one way or the other, but the when clause can be updated to include these in the future if necessary. |
|
/gcbrun |
|
No major YANG version changes in commit 3f64e22 |
|
@jorabada can you please comment? |
I don't think I agree with this. The es-import route-target can be autoderived for all types. rfc7432bis states that is autoderived for types 1..3, and MAY be autoderived for the other types. If you do this for type 0, I don't see why you wouldn't do it for the other types. Also, I suppose implementations do autoderivation as a bare minimum, and explicit configuration is supported only in some implementations out there. |
|
Would it make more sense to change the "es-import-route-target" leaf to be a union of either an explicit value, or an enum with an AUTO member? That would then allow the user to be more explicit, both when configuring AUTO, and when configuring an explicit es-import-rt. The explicit configuration portion of the union could be made conditional on types 0, 4, and 5, to adhere to the new draft RFC. |
|
Thanks @abamberger-arista - as I was saying, I don't think this change is necessary at all. If there is really push from people to have it, your original suggestion is simpler: When configured explicitly, the es-import-route-target will be used. Otherwise, the autoderived one is used. |
|
@jorabada I guess I'm not seeing a good reason not to add it. It's something explicitly defined in the RFC, it's backwards compatible, and it's optional. I can revert back to the original proposal (which I agree is simpler, although it would technically allow users to push an explicit es-import-rt with ESI types that per the RFC are always supposed to be auto-generated, that is, types 1-3). Are there any objections to getting this in in its original form (a single additional optional es-import-rt leaf)? |
As I said, I don't think it is necessary, but I won't object if you add it (in its original form)... thanks. |
* Add a new leaf "es-import-route-target" to the Ethernet Segment config model to allow the explicit configuration of an ES-import route target as per RFC7432 Section 7.6
…r-arista/openconfig-public into ethernet-segment-model-updates
|
Thanks for taking a look again, I've restored it to its original form. I understand this may be a niche use case in practice, but since I don't really see much of a downside in adding it, and it will allow implementations that do support it to be a bit more full featured when using OC for configuration. @dplore are all concerns resolved from your end on this? |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
| "Received ES routes with an ES-Import extended community set to this value | ||
| are imported into this ethernet segment"; |
There was a problem hiding this comment.
Can you add text regarding auto derived and what happens if configured? ie:
"When configured by a user, the es-import-route-target will be used, otherwise the system automatically derives the value used."
Also, end the sentence with a period please. Thanks!
There was a problem hiding this comment.
Setting to last call for comments. THis will merge Oct 21, 2024
|
/gcbrun |
|
/gcbrun |
Change Scope
The existing openconfig ethernet segment model has no way to configure the ES-import route target (defined in RFC7432 Section 7.6) for a type 0 operator configured ESI. This proposal adds a new field, “es-import-route-target”, to the existing ES config model, to allow the explicit configuration of an ES-import route target.
Because this is a new leaf being added, this change is fully backwards compatible.
New tree state after proposed change (additions in bold):
module: openconfig-ethernet-segments +--rw ethernet-segments +--rw ethernet-segment* [name] +--rw config | +--rw es-import-route-target? oc-yang-types:mac-address | ... +--ro state +--ro es-import-route-target? oc-yang-types:mac-address ...New Yang Paths:
Platform Implementations
Arista EOS:
https://www.arista.com/en/um-eos/eos-vxlan-configuration#topic_ckc_dh4_ynb
https://www.arista.com/en/support/toi/eos-4-22-0f/14236-evpn-vxlan-all-active-multihoming
interface Port-Channel1 evpn ethernet-segment identifier 00aa:bbbb:cccc:dddd:eeee route-target import 12:23:34:45:56:67